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Foreword 



rd , 



This Technical Specification has been produced by the 3 Generation Partnership Project (3GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 



Introduction 



The interface Itf-N, defined in 3GPP TS 32.102 [2], is built up by a number of Integration Reference Points (IRPs) and 
a related Name Convention, which realise the functional capabilities over this interface. The basic structure of the IRPs 
is defined in 3GPP TS 32.101 [1] and 3GPP TS 32.102 [2]. 

Due to the growing number of specifications to model new services and Resource Models for Configuration 
Management (CM), as well as the expected growth in size of each of them from 3GPP Release 4 onwards, a new 
structure of the specifications is already needed in Release 4. This structure is needed for several reasons, but mainly to 
enable more independent development and release for each part, as well as a simpler document identification and 
version handling. Another benefit would be that it becomes easier for bodies outside 3GPP, such as the ITU-T, to refer 
to telecom management specifications from 3GPP. The new structure of the specifications does not lose any 
information or functionality supported by the Release 1999. 

In addition to the restructuring, the need to define some new IRPs for CM, compared to Release 1999, has also been 
identified. Firstly, a new IRP for the Bulk CM, and secondly, one for each of the NRM parts (Generic, Core Network, 
UTRAN and GERAN NRM). 

Finally, the Notification IRP (in Release 1999: 32.106-1 to -4) and the Name convention for Managed Objects (in 
Release 1999: 32.106-8) have been moved to a separate number series used for specifications common between several 
management areas (e.g. CM, FM, PM). 
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Table: Mapping between Release '99 and the new specification numbering scheme 



R99 Old 
no. 


Old (R99) specification title 


Rel-4 
New no. 


New (Rel-4) specification title 


32.106-1 


3G Configuration Management: Concept and Requirements 


32.600 


3G Configuration Management: Concept and 
High-level Requirements 


32.106-1 


<Notification IRP requirements from 32.106-1 and 32.106-2> 


32.301 


Notification IRP: Requirements 


32.106-2 


Notification IRP: IS 


32.302 


Notification IRP: Information Service 


32.106-3 


Notification IRP: CORBA SS 


32.303 


Notification IRP: CORBA SS 


32.106-4 


Notification IRP: CMIP SS 


32.304 


Notification IRP: CMIP SS 


32.106-8 


Name convention for Managed Objects 


32.300 


Name Convention for Managed Objects 


32.106-1 


<Basic CM IRP IS requirements from 32.106-1 and 32.106-5> 


32.601 


Basic CM IRP: Requirements 


32.106-5 


Basic CM IRP IM (Intro & IS part) 


32.602 


Basic CM IRP: Information Service 


32.106-6 


Basic CM IRP CORBA SS (IS related part) 


32.603 


Basic CM IRP: CORBA SS 


32.106-7 


Basic CM IRP CMIP SS (IS related part) 


32.604 


Basic CM IRP: CMIP SS 


32.106-8 


Name convention for Managed Objects 


32.300 


Name Convention for Managed Objects 


- 


- 


32.611 


Bulk CM IRP: Requirements 


- 


- 


32.612 


Bulk CM IRP: Information Service 


- 


- 


32.613 


Bulk CM IRP: CORBA SS 


- 


- 


32.614 


Bulk CM IRP: CMIP SS 






32.615 


Bulk CM IRP: XML file format definition 


32.106-1 


<Basic CM IRP Generic NRM requirements from 32.106-1 and 
32.106-5> 


32.621 


Generic Network Resources IRP: Requirements 


32.106-5 


Basic CM IRP IM (Generic NRM part) 


32.622 


Generic Network Resources IRP: NRM 


32.106-6 


Basic CM IRP CORBA SS (Generic NRM related part) 


32.623 


Generic Network Resources IRP: CORBA SS 


32.106-7 


Basic CM IRP CMIP SS (Generic NRM related part) 


32.624 


Generic Network Resources IRP: CMIP SS 


32.106-1 


<Basic CM IRP CN NRM requirements from 32.106-1 and 
32.106-5> 


32.631 


Core Network Resources IRP: Requirements 


32.106-5 


Basic CM IRP IM (CN NRM part) 


32.632 


Core Network Resources IRP: NRM 


32.106-6 


Basic CM IRP CORBA SS (CN NRM related part) 


32.633 


Core Network Resources IRP: CORBA SS 


32.106-7 


Basic CM IRP CMIP SS (CN NRM related part) 


32.634 


Core Network Resources IRP: CMIP SS 


32.106-1 


<Basic CM IRP UTRAN NRM requirements from 32.106-1 and 
32.106-5> 


32.641 


UTRAN Network Resources IRP: Requirements 


32.106-5 


Basic CM IRP IM (UTRAN NRM part) 


32.642 


UTRAN Network Resources IRP: NRM 


32.106-6 


Basic CM IRP CORBA SS (UTRAN NRM related part) 


32.643 


UTRAN Network Resources IRP: CORBA SS 


32.106-7 


Basic CM IRP CMIP SS (UTRAN NRM related part) 


32.644 


UTRAN Network Resources IRP: CMIP SS 






32.651 


GERAN Network Resources IRP: Requirements 






32.652 


GERAN Network Resources IRP: NRM 






32.653 


GERAN Network Resources IRP: CORBA SS 






32.654 


GERAN Network Resources IRP: CMIP SS 
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Scope 



The present document (Generic Network Resources IRP: Network Resource Model) defines an Integration Reference 
Point (IRP) through which an IRP Agent' (typically an Element Manager or Network Element) can communicate 
Network Management related information to one or several 'IRPManagers' (typically Network Managers). 

The present document specifies a generic Network Resource Model, NRM (also referred to as a Management 
Information Model - MIM) with definitions of Managed Object Classes. 

The Configuration Management (CM) area is very large. The intention is to split the specification of the related 
interfaces in several IRPs. In addition to the subject IRP, it is expected that IRPs will be defined for functional areas like 
Security management. Software management. Network & Service provisioning, etc. An important aspect of such a split 
is that the Network Resource Models (NRMs) defined in different IRPs are consistent. The Generic Network Resources 
IRP here provides a base for all resource modelling. 

To summarize, the Generic Network Resources IRP main purpose is to define a generic Network Resource Model that 
constitutes a base from which other (more specialized) resource models can inherit or have associations with. 



References 



The following documents contain provisions which, through reference in this text, constitute provisions of the present 
document. 

• References are either specific (identified by date of publication, edition number, version number, etc.) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including 
a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same 
Release as the present document. 

[I] 3GPP TS 32.101: "3G Telecom Management principles and high level requirements". 

[2] 3GPP TS 32.102: "3G Telecom Management architecture". 

[3] 3GPP TS 32.302: "Telecommunication Management; Configuration Management; 

Part 2: Notification Integration Reference Point; Information Service Version 1". 

[4] ITU-T Recommendation M.3100 (07/95): "Generic Network Information Model". 

[5] ITU-T Recommendation M.3100 Corrigendum 1 (07/98)". 

[6] ITU-T Recommendation M. 3 1 00 Amendment 1 (03/99)" . 

[7] ITU-T Recommendation X.710 (1991): "Common Management Information Service Definition 

for CCITT Applications". 

[8] ITU-T Recommendation X.721 (02/92): "Information Technology - Open Systems Interconnection 

- Structure of Management Information: Definition of Management Information". 

[9] ITU-T Recommendation X.730 (01/92): "Information Technology - Open Systems Interconnection 

- Systems Management: Object Management Function". 

[10] ITU-T Recommendation X.733 (02/92): "Information Technology - Open Systems Interconnection 

- Alarm Reporting Function". 

[II] 3GPP TS 32.1 1 1-2: "Telecommunication Management; Fault Management; 
Part 2: Alarm Integration Reference Point; Information Service Version 1". 

[13] 3GPP TS 32.300: "Name Convention for Managed Objects". 
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[14] 
[15] 
[16] 



3GPP TS 32.600: "3G Configuration Management: Concepts and requirements". 

3GPP TS 23.002: "Network Architecture". 

3GPP TS 32.642: "UTRAN Network Resources IRP : Network Resource Model". 



3.1 



Definitions and abbreviations 



Definitions 



For the purposes of the present document, the following terms and definitions apply. For terms and definitions not 
found here, please refer to 3GPP TS 32.101 [1], 3GPP TS 32.102 [2] and 3GPP TS 32.600 [14]. 

Association: In general it is used to model relationships between Managed Objects. Associations can be implemented in 
several ways, such as: 

(1) name bindings , 

(2) reference attributes , and 

(3) association objects . 

This IRP stipulates that containment associations shall be expressed through name bindings, but it does not stipulate the 
implementation for other types of associations as a general rule. These are specified as separate entities in the object 
models (UML diagrams). Currently however, all (non-containment) associations are modelled by means of reference 
attributes of the participating MOs. 

Managed Element (ME): An instance of the Managed Object Class ManagedElement. 

Managed Object (MO): In the context of the present document, a Managed Object (MO) is a software object that 
encapsulates the manageable characteristics and behaviour of a particular Network Resource. The MO is instance of a 
MO class defined in a MIM/NRM. An MO class has attributes that provide information used to characterize the objects 
that belong to the class (the term "attribute" is taken from TMN and corresponds to a "property" according to CIM). 
Furthermore, an MO class can have operations that represent the behaviour relevant for that class (the term "operation" 
is taken from TMN and corresponds to a "method" according to CIM). An MO class may support notifications that 
provide information about an event occurrence within a network resource. 

Management Information Base (MIB): A MIB is an instance of an NRM and has some values on the defined 
attributes and associations specific for that instance. In the context of the present document, an MIB consists of: 

(1) a Name space (describing the MO containment hierarchy in the MIB through Distinguished Names), 

(2) a number of Managed Objects with their attributes and 

(3) a number of Associations between these MOs. Also note that TMN (ITU-T Recommendation X.710 [7]) 
defines a concept of a Management Information Tree (also known as a Naming Tree) that corresponds to the 
name space (containment hierarchy) portion of this MIB definition. Figure 1 depicts the relationships between 
a Name space and a number of participating MOs (the shown association is of a non-containment type) 




^ 



Namespace (containment hierarchy) 
O Q MO y MIB 
Associatbn 



J 
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Figure 1 : Relationships between a Name space and a number of participating IVIOs 



Management Information Model (MIM): Also referred to as NRM - see the definition below. 

Name space: A name space is a collection of names. The IRP name convention (see 3GPP TS 32.300 [13]) restricts the 
name space to a hierarchical containment structure, including its simplest form - the one-level, flat name space. 
All Managed Objects in a MIB shall be included in the corresponding name space and the MIB/name space shall only 
support a strict hierarchical containment structure (with one root object). A Managed Object that contains another is 
said to be the superior (parent); the contained Managed Object is referred to as the subordinate (child). The parent of all 
MOs in a single name space is called a Local Root. The ultimate parent of all MOs of all managed systems is called the 
Global Root. 

Network Resource Model (NRM): A model representing the actual managed telecommunications network resources 
that a System is providing through the subject IRP. An NRM describes Managed Object Classes, their associations, 
attributes and operations. The NRM is also referred to as "MIM" (see above), which originates from the ITU-T TMN. 

Node B: A logical node responsible for radio transmission/reception in one or more cells to/from the User Equipment. 
It terminates the lub interface towards the RNC. 



3.2 



Abbreviations 



For the purposes of the present document, the following abbreviations apply: 

AUG Authentication Centre 

BG Border Gateway 

CIM Common Information Model 

CMIP Common Management Information Protocol 

CMIS Common Management Information Service 

CN Core Network 

CORBA Common Object Request Broker Architecture 

DMTF Distributed Management Task Force 

DN Distinguished Name (see 3GPP TS 32.300 [13]) 

EIR Equipment Identity Register 

EM Element Manager 

FM Fault Management 

GDMO Guidelines for the Definition of Managed Objects 

GGSN Gateway GPRS Support Node 

GMSC Gateway MSC 

GPRS General Packet Radio System 

HLR Home Location Register 

IDL Interface Definition Language 

IRP Integration Reference Point 

ITU-T International Telecommunication Union, Telecommunication Sector 

lub Interface between RNC and Node B 

LDAP Lightweight Directory Access Protocol 

ME Managed Element 

MIB Management Information Base 

MIM Management Information Model 

MIT Management Information Tree (or Naming Tree) 

MO Managed Object 

MOC Managed Object Class 

MOI Managed Object Instance 

MSC Mobile Services Switching Centre 

NE Network Element 

NM Network Manager 

NR Network Resource 

NRM Network Resource Model 

OSI Open Systems Interconnection 

PM Performance Management 

RDN Relative Distinguished Name (see 3GPP TS 32.300 [13]) 
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RNC Radio Network Controller 

SGSN Serving GPRS Support Node 

SMI Structure of Management Information 

SMS Short Message Service 

SMS-GMSC SMS Gateway MSC 

SMS-IWMSC SMS Interworking MSC 

SNMP Simple Network Management Protocol 

SS Solution Set 

TMN Telecommunications Management Network 

UML Unified Modelling Language 

UMTS Universal Mobile Telecommunications System 

VLR Visitor Location Register 

WBEM Web-Based Enterprise Management 

XML extensible Mark-up Language 
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4 System overview 

4.1 System context 

Figure 2 and Figure 3 identify system contexts of the subject IRP in terms of its implementation called IRP Agent and 
the user of the IRP Agent, called IRPManager. For a definition of IRPManager and IRP Agent, see 3GPP TS 32.102 [2]. 

The IRP Agent implements and supports the Generic Network Resources IRP. The IRP Agent can be an Element 
Manager (EM) or a mediator that interfaces one or more NEs (see Figure 2), or it can be a Network Element (NE) (see 
Figure 3). In the former case, the interfaces (represented by a thick dotted line) between the EM and the NEs are not 
subject of this IRP. 

An IRPManager using this IRP shall choose one of the two System Contexts defined here, for each NE. For instance, if 
an EM is responsible for managing a number of NEs, the NM shall access this IRP through the EM and not directly to 
those NEs. For another IRP though, the System Context may be different. 
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Figure 2: System Context A 
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Figure 3: System Context B 



4.2 Compliance rules 



For general definitions of compliance rules related to qualifiers (Mandatory/Optional/Conditional) for operations, 
notifications and parameters (of operations and notifications) please refer to 3GPP TS 32.102 [2]. 

The following defines the meaning of Mandatory and Optional MOC attributes and associations between MOCs, in 
Solution Sets to the Basic CM IRP: 

• The IRPManager shall support all mandatory attributes/associations. The IRPManager shall be prepared to 
receive information related to mandatory as well as optional attributes/associations without failure; however 
the IRPManager does not have to support handling of the optional attributes/associations. 
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• The IRP Agent shall support all mandatory attributes/associations. It may support optional 
attributes/associations. 

An IRP Agent that incorporates vendor-specific extensions shall support normal communication with a 3GPP 
SA5-compliant IRPManager with respect to all Mandatory and Optional managed object classes, attributes, 
associations, operations, parameters and notifications without requiring the IRPManager to have any knowledge of the 
extensions. 

Given that 

• rules for vendor-specific extensions remain to be fully specified, and 

• many scenarios under which IRPManager and IRP Agent interwork may exist, 

it is recognised that in Release 4/5 the IRPManager, even though it is not required to have knowledge of vendor-specific 
extensions, may be required to be implemented with an awareness that extensions can exist and behave accordingly. 
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5 Modelling approach 

This clause identifies the modelling approach adopted and used in this IRP. 
As previously described, this IRP is structured in: 

(1) requirements for a generic Network Resources Model, and 

(2) an IRP Network Resource Model (the subject document) that specifies the interface in a protocol neutral 
manner, and 

(3) a number of IRP Solution Sets that provide the actual definitions of object classes defined in the IRP Network 
Resources Model for each protocol environment. 

Figure 4 shows the structure of the Generic Network Resources IRP (including a number of possible Solution Sets). 



Generic Network Resources IRP: Requirements 



IRP Information Service - operations and notifications (not specified by this 
IRP) 

Network Resource Model (NRM) with MO classes (in UML) 




SNMP 

Solutio 

nSet 



LDAP 

Solutio 

n Set 



WBEM 

Solutio 

nSet 



CORBA 

Solutio 

n Set 



CMIP 

Solutio 

nSet 



Protocol 
independent 



Protocol 
specific 



Figure 4: Generic Networl< Resources IRP Structure with example Solution Sets 

The Network Resource Model (NRM) 

is a protocol-independent model that specifies a number of Managed Object classes (with attributes and associations), 
which are relevant in the context of the subject IRP. Each Solution Set shall provide an implementation of this resource 
model with: 

a) references to standard models that are applicable for the corresponding protocol environment, and 

b) extensions to these standard models for the parts of the NRM that are not covered. 

The NRM defined in the subject IRP bases its design mainly on work captured in ITU-T M.3100 [4], [5], [6]. However, 
as described in the Scope of the present document (clause 1): The model is highly simplified for the purpose of the NM, 
based on the assumption that all of the detailed CM actions, including fault correction after one or more alarms, are 
performed by an Element Manager which knows the vendor-specific NRM and configuration, and which is launched by 
the NM when necessary. 

Moreover, the classes defined herein are very basic, only for the necessary support of Fault Management (FM) and 
Performance Management (PM), which means that they contain very few attributes - basically only for naming. 

In addition, also some basic associations between some of the classes are defined. 
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Detailed mapping to the actual standard model is described in each Solution Set. It is important to note that if one 
selects a specific management protocol, one should also as base use existing de-facto conventions and standard resource 
models that are applicable to that protocol environment. Examples: 

• SNMP Solution Sets (SMI-specifications) should be consistent with existing standard SNMP MIB-modules in 
order to function in an SNMP environment. 

• CMIP Solution Sets (GDMO-specifications) should be based on standard models hke ITU-T X.721 [8] and ITU- 
T M.3100 [4], [5], [6] in order to function in an OSI/TMN environment. 

• WBEM Solution Sets (MOF/XML-specifications) should be based on CIM to function in a WBEM 
environment. 

NOTE: CORBA Solution Sets are special in the sense that no such corresponding de-facto standard models exist, 
and CORBA/IDL is transparent to any model. Thus, one has full freedom to choose the same model for 
the CORBA Solution Set to this IRP, as the IRP Information Model defined herein. 

Finally, all solution sets shall of course be consistent with the IRP Network Resource Model defined herein. 

Clause 6 below defines an information model in terms of Information Object Classes (lOCs), attributes and 
relationships, according to the modelling approach described in TS 32.102 [2]. Clause 7 defines a management 
information model in terms of Managed Object Classes (MOCs), according to the modelling approach used in Release 
99. 



6 Information Object Class definitions 

6.1 Information object classes 

6.1 .1 Information entities imported local labels 

None. 

6.1.2 Class diagram 

6.1 .2.1 Attributes and relationships 

This sub-clause depicts the set of lOCs that encapsulate information relevant for this service. This sub-clause provides 
the overview of all information object classes in UML. Subsequent sub-clauses provides more detailed specification of 
various aspects of these information object classes. 
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Figure 5 shows the containment/naming hierarchy and the associations of the generic information object classes defined 
in this TS. 

NOTE: The information object containment relationships are, in the diagram(s) below, indicated by UML 
"Aggregation by reference" ("hollow diamonds"). 
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NOTE 1 : ManagedElement may be contained in either a SubNetwork or an MeContext instance, or have no parent instance at 

all. 
NOTE 2: The listed cardinality numbers represent transient as well as steady-state numbers, and reflect all managed object 

creation and deletion scenarios. 
NOTE 3: Each instance of the VsDataContainer shall only be contained under one MOC. The VsDataContainer can be 

contained under MOCs defined in other NRMs. 
NOTE 4: If the configuration contains several instances of SubNetwork, exactly one SubNetwork instance shall directly or 

indirectly contain all the other SubNetwork instances. 
NOTE 5: The SubNetwork instance not contained in any other instance of SubNetwork is referred to as "the root SubNetwork 

instance". 
NOTE 6: ManagementNode shall be contained in the root SubNetwork instance. 
NOTE 7: If contained in a SubNetwork instance, IRPAgent shall be contained in the root SubNetwork instance. 

Figure 5: Generic NRI\/I Containment/Naming and Association diagram 

Each Managed Object is identified with a Distinguished Name (DN) according to 3GPP TS 32.300 [13] that expresses 
its containment hierarchy. As an example, the DN of a ManagedElement instance could have a format like: 

SubNetwork=Sweden,MeContext=MEC-Gbg-l, ManagedElement =RNC-Gbg-1 . 
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6.1.2.2 Inheritance 

This sub-clause depicts the inheritance relationships that exists between information object classes. 
Figure 6 shows the inheritance diagram. 
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Figure 6: Generic Network Resources IVIodel Inhieritance IHierarchiy 

6.1 .3 Information object class definitions 
6.1.3.1 GenericIRP 



6.1.3.1.1 



Definition 



This information Object Class represents the IRP capability associated with each IRP Agent. This IOC cannot be 
instantiated. It is defined for sub-classing purposes. At least one instance of a sub-class of GenericIRP shall be present 
for every IRP Agent instance. 



6.1.3.1.2 



Attributes 



Table 1 : Attributes of GenericIRP 



Attribute Name 


Support Qualifier 


IRPId 


M 



6.1.3.2 



6.1.3.2.1 



IRPAgent 



Definition 



This information Object Class represents the functionality of an IRPAgent. It shall be present. For a definition of 
IRPAgent, see 3GPP TS 32.102 [2]. 

Restriction in R4: The IRPAgent will be contained under a managed object as follows (only one of the options shall be 
used): 

1 . ManagemenlNode, if the configuration contains a ManagemenlNode; 

2. SubNetwork, if the configuration contains a SubNetwork and no ManagementNode; 

3. ManagedElement, if the configuration contains no ManagementNode or SubNetwork. 
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6.1.3.2.2 



Attributes 



Table 2: Attributes of irp Agent 



6.1.3.3 



Attribute Name 


Support Qualifier 


irpAgentId 


M 


systemDN 


C 



ManagedElement 



6.1.3.3.1 



Definition 



This information Object Class represents telecommunications equipment or TMN entities within the 

telecommunications network that performs Managed Element (ME) functions, i.e. provides support and/or service to the 

subscriber. 

An ME communicates with a manager (directly or indirectly) over one or more interfaces for the purpose of being 

monitored and/or controlled. MEs may or may not additionally perform element management functionality. 

An ME contains equipment that may or may not be geographically distributed. An ME is often referred to as a 

"Network Element". This class is similar to the Managed Element class specified in ITU-T M.3100 [4], [5], [6]. 

A ManagedElement may be contained in either a SubNetwork or in an MeContext instance. A single ManagedElement 
seen over the Itf-N may also exist stand-alone with no parent at all. 

The ManagedElement MOC may be used to represent combined ME functionality (as indicated by the 
managedElementType attribute and the contained instances of different functional MOCs). 

Single function ManagedElement managed object instances will have a 1..1 containment relationship to a function 
Managed Object (in this context a function MO is an MO derived from the ManagedFunction MOC). Multiple function 
ManagedElement managed object instances will have a 1..N containment relationship to function Managed Objects. 



6.1.3.3.2. 



Attributes 



Table 3: Attributes of ManagedElement 



Attribute Name 


Support Qualifier 


managed Elementld 


M 


dnPrefix 


C 


managedElementType 


M 


userLabel 


M 


vendorName 


M 


userDefinedState 


M 


locationName 


M 


swVersion 


M 



6.1.3.4 



ManagedFunction 



6.1.3.4.1 



Definition 



This information Object Class is provided for sub-classing only. It provides attribute(s) that are common to functional 
Information Object Classes. Note that a Managed Element may contain several managed functions. The 
ManagedFunction may be extended in the future if more common characteristics to functional objects are identified. 
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6.1.3.4.2 



Attributes 



Table 4: Attributes of ManagedFunction 



6.1.3.5 



Attribute Name 


Support Qualifier 


userLabel 


M 



ManagementNode 



6.1.3.5.1 



Definition 



This information Object Class represents a telecommunications management system (EM) within the TMN that 
contains functionality for managing a number of Managed Elements (MEs). The management system communicates 
with the MEs directly or indirectly over one or more interfaces for the purpose of monitoring and/or controlling these 
MEs. 

This class has similar characteristics as the ManagedElement. The main difference between these two classes is that the 
ManagementNode has a special association to the managed elements that it is responsible for managing. 



6.1.3.5.2 



Attributes 



Table 5: Attributes of ManagementNode 



Attribute Name 


Support Qualifier 


managementNodeld 


M 


userLabel 


M 


VendorName 


M 


UserDefinedState 


M 


LocationName 


M 


swVersion 


M 



6.1.3.6 



MeContext 



6.1.3.6.1 



Definition 



This information Object Class is introduced for naming purposes. It may support creation of unique DNs in scenarios 
when some MEs have the same RDNs due to the fact that they have been manufacturer pre-configured. 
If some MEs have the same RDNs (for the above mentioned reason) and they are contained in the same SubNetwork 
instance, some measure shall be taken in order to assure the global uniqueness of DNs for all MOIs under those MEs. 
One way could be to set different DnPrefixes for those NEs, but that would require either that: 

a) all LDNs or DNs are locally modified using the new DnPrefix for the upper portion of the DNs, or 

b) a mapping (translation) of the old LDNs or DNs to the new DNs every time they are used externally, e.g. in alarm 
notifications. 

As both the two alternatives above may involve unacceptable drawbacks (as the old RDNs for the MEs then would have 
to be changed or mapped to new values), using MeContext offers a new alternative to resolve the DN creation. Using 
MeContext as part of the naming tree (and thus the DN) means that the DnPrefix, including a unique MeContext for 
each ME, may be directly concatenated with the LDNs, without any need to change or map the existing ME RDNs to 
new values. 

MeContext have 0..N instances. It may exist even if no SubNetwork exists. Every instance of MeContext contains 
exactly one ManagedElement during steady-state operations. 
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6.1.3.6.2 



Attributes 



Table 6: Attributes of MeContext 



6.1.3.7 



SubNetwork 



Attribute Name 


Support Qualifier 


meContextId 


M 


dnPrefix 


C 



6.1.3.7.1 Definition 

This information object class represents a set of managed entities as seen over the Itf-N. 

There may be zero or more instances of a SubNetwork. It shall be present if either a ManagementNode or multiple 
ManagedElements are present (i.e. ManagementNode and multiple ManagedElement instances shall have SubNetwork 
as parent). 

The SubNetwork instance not contained in any other instance of SubNetwork is referred to as "the root SubNetwork 
instance". 



6.1.3.7.2 



Attributes 



Table 7: Attributes of SubNetwork 



6.1.3.8 



Top 



Attribute Name 


Support Qualifier 


subNetworkId 


M 


dnPrefix 


C 


UserLabel 


M 


userDefinedNetworkType 


M 



6.1.3.8.1 



Definition 



This information object class is introduced for generaUsation purposes. AU information object classes defined in all TS 
that claim to be conformant to 32. 102[2] shall inherit from Top. 



6.1.3.8.2 



Attributes 



6.1.3.9 



Table 8: Attributes of Top 



Attribute Name 


Support Qualifier 


objectClass 


M 


objectlnstance 


M 



Class VsDataContainer 



6.1.3.9.1 



Definition 



The 'VsDataContainer' managed object is a container for vendor specific data. The number of instances of the 
'VsDataContainer' can differ from vendor to vendor. This MOC shall only be used by the Bulk CM IRP for the UTRAN 
and GERAN object models. 
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6.1.3.9.2 



Attribute 



Table 9: Attributes of VsDataContainer 





,^^^ Qualifier 


vsDataContainerld 


M 


vsDataType 


M 


vsData 


M 


vsDataFormatVersion 


M 



6.1 .4 Information relationship definitions 
6.1.4.1 MgmtAssociation (M) 

6.1.4.1.1 Definition 

This association is used to represent relationships between one or more MEs and the ManagementNode that is 
responsible for managing the MEs. It has two roles, named Manages and ManagedBy. The role 'Manages' models the 
fact that a ManagementNode is responsible for managing zero or more MEs, and the role ManagedBy models the fact 
that an ME is managed by zero or one ManagementNode. Each role is in the MOC definition mapped to a reference 
attribute with the same name. 

6.1.4.1.2 Roles 

The roles involved in the relation MgmtAssociation are listed in this table. 

Table 10: Roles of the relation MgmtAssociation 



Name 


Definition 


Manages 


This role refers to a list of the DN(s) of the related IVIanagedElement instance(s). This is a reference 
attribute modelling the role (of the association MgmtAssociation) that this managementNode is 
responsible for managing zero or more MEs. 


IsManagedBy 


This role refers to the DN of the related managementNode instance. This is a reference attribute 
modelling the role (of the association MgmtAssociation) that this ME is managed by zero or one 
managementNode. 



6.1.4.1.3 



Constraints 



There is no constraint for this relationship. 

6.1 .4.2 SubNetwork-ManagementNode 

6.1.4.2.1 Definition 

This represents the containment relationship between SubNetwork and ManagementNode. 
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6.1.4.2.2 



Roles 



Name 


Definition 


contains 


This role is played by objects of the information object class ManagementNode. 


isContainedIn 


This role is played by objects of the information object class SubNetwork. 


6.1.4.2.3 Constraints 


Name 


Definition 


ManagementNodeContai 
nedlnRootSubNetwork 


" An instance of the IVIanagementNode IOC sliall be contained in the root SubNetwork 
instance. " 



6.1.4.3 



SubNetwork-MeContext 



6.1.4.3.1 Definition 

This represents the containment relationship between SubNetwork and MeContext. 

6.1.4.3.2 Roles 



Name 


Definition 


contains 


This role is played by objects of the information object class MeContext. 


isContainedIn 


This role is played by objects of the information object class SubNetwork. 



6.1.4.3.3 Constraints 

There is no constraint for this relationship. 

6.1.4.4 SubNetwork-SubNetwork 

6.1.4.4.1 Definition 

This represents the containment relationship between SubNetwork and SubNetwork. 



6.1.4.4.2 



Roles 



Name 


Definition 


contains 


This role is played by objects of the information object class SubNetwork. 


IsContainedIn 


This role is played by objects of the information object class SubNetwork. 


6.1.4.4.3 Constraints 


Name 


Definition 


OneSubNetworkContain 
sAIIOthers 


" If the configuration contains several instances of the SubNetwork IOC, exactly one 
SubNetwork instance shall directly or indirectly contain all the other SubNetwork instances. " 



6.1.4.5 SubNetwork-IRPAgent 

6.1.4.5.1 Definition 

This represents the containment relationship between SubNetwork and IRP Agent. 
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6.1.4.5.2 Roles 



Name 


Definition 


contains 


This role is played by objects of the information object class IRP Agent. 


isContainedIn 


This role is played by objects of the information object class SubNetwork. 


6.1.4.5.3 Constraints 


Name 


Definition 


IRPAgentContainedlnRo 
otSubNetwork 


" If an instance of the IRPAgent IOC is contained in a SubNetwork instance, this instance 
shall be the root SubNetwork instance. " 



6.1 .4.6 SubNetwork-ManagedElement 

6.1.4.6.1 Definition 

This represents the containment relationship between SubNetwork and ManagedElement. 

6.1.4.6.2 Roles 



Name 


Definition 


contains 


This role is played by objects of the information object class ManagedElement. 


IsContainedIn 


This role is played by objects of the information object class SubNetwork. 



6.1.4.6.3 Constraints 

There is no constraint for this relationship. 

6.1.4.7 MeContext-ManageclElement 

6.1.4.7.1 Definition 

This represents the containment relationship between MeContext and ManagedElement. 

6.1.4.7.2 Roles 



Name 


Definition 


Contains 


This role is played by objects of the information object class ManagedElement. 


IsContainedIn 


This role is played by objects of the information object class MeContext. 



6.1.4.7.3 Constraints 

There is no constraint for this relationship. 

6.1.4.8 ManageclElement-IRPAgent 

6.1.4.8.1 Definition 

This represents the containment relationship between ManagedElement and IRPAgent. 

6.1.4.8.2 Roles 



Name 


Definition 


Contains 


This role is played by objects of the information object class IRPAgent. 


IsContainedIn 


This role is played by objects of the information object class ManagedElement. 



6.1.4.8.3 Constraints 

There is no constraint for this relationship. 
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6.1.4.9 IRPAgent-GenericIRP 

6.1.4.9.1 Definition 

This represents the containment relationship between IRP Agent and GenericIRP. 

6.1.4.9.2 Roles 



Name 


Definition 


Contains 


This role is played by objects of the information object class GenericIRP. 


IsContainedIn 


This role is played by objects of the information object class IRP Agent. 



6.1.4.9.3 Constraints 

There is no constraint for this relationship. 

6.1 .5 Information attribute definitions 
6.1 .5.1 Definitions and legal values 

The table below defines the attributes that are present in several information object classes of this TS. 
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Table 1 1 : Attributes 



Attribute Name 


Definition 


Legal Values 


dnPrefix 


It carries the DN Prefix information as defined in Annex of 32.300 [13]. It 
sliall only be specified if the instance of the information object class 
supporting this attribute is a local root instance of the IVIIB. Otherwise the 
value shall carry the NULL semantics. 




managedElementId 


An attribute whose 'name+value' can be used as an RDN when naming an 
instance of the ManagedElement object class. This RDN uniquely identifies 
the object instance within the scope of its containing (parent) object instance. 










managedElementlype 


The type of managed element. It is a multi-valued attribute with one or more 
elements. Thus, it may represent one IVIE functionality, e.g. an RNC, or a 
combination of more than one functionality e.g. an MSC/HLR. 

The actual syntax and encoding of this attribute is Solution Set specific. 


RNC, NodeB, 
BSS, MSC, HLR, 
VLR, AuC, EIR, 
SMS-IWMSC, 
SMS-GMSC, 
GMSC, SGSN, 
GGSN, BG, BS, 
CBC, CGF, 
GMLC, GMSC 
Server, IWF, 
MGW, MNP- 
SRF, MSC 
Server, NPDB, R- 
SGW, SCF, 
SMLC, SRF, 
SSF. 


irpAgentId 


An attribute whose 'name+value' can be used as an RDN when naming an 
instance of this object class. This RDN uniquely identifies the object instance 
within the scope of its containing (parent) object instance. 




irpid 


An attribute whose 'name+value' can be used as an RDN when naming an 
instance of this object class. This RDN uniquely identifies the object instance 
within the scope of its containing (parent) object instance. 




locationName 


The physical location of this entity (e.g. an address). 




managementNodeld 


An attribute whose 'name+value' can be used as an RDN when naming an 
instance of this object class. This RDN uniquely identifies the object instance 
within the scope of its containing (parent) object instance. 




meContextld 


An attribute whose 'name+value' can be used as an RDN when naming an 
instance of this object class. This RDN uniquely identifies the object instance 
within the scope of its containing (parent) object instance. 




objectClass 


An attribute which captures the name of the class from which the object 
instance is an occurrence of. 




objectlnstance 


An information which captures the Distinguished Name of any object. 




subNetworkId 


An attribute whose 'name+value' can be used as an RDN when naming an 
instance of the SubNetwork object class. This RDN uniquely identifies the 
object instance within the scope of its containing (parent) object instance. 




swVersion 


The software version of the ManagementNode or ManagedElement (this is 
used for determining which version of the vendor specific information is valid 
for the ManagementNode or ManagedElement). 




systemDN 


The Distinguished Name (DN) of IRPAgent. defined in 3GPP TS.32.300. 




userDefinedNetworklype 


Textual information regarding the type of network, e.g. UTRAN. 




userDefinedState 


An operator defined state for operator specific usage. (See also Note below) 




userLabel 


A user-friendly name of this object. 




vendorName 


The name of the vendor. 




vsData 


Vendor specific attributes of the type vsDataType. The attribute definitions 
including constraints (value ranges, data types, etc.) are specified in a 
vendor specific data format file. 




vsDataContainerld 


An attribute whose 'name+value' can be used as an RDN when naming an 
instance of this object class. This RDN uniquely identifies the object instance 
within the scope of its containing (parent) object instance. 




vsDataPormatVersion 


Name of the data format file, including version. 




vsDatalype 


Type of vendor specific data contained by this instance, e.g. relation specific 
algorithem parameters, cell specific parameters for power control or re- 
selection or a timer. The type itself is also vendor specific. 
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7 Mapping from lOCs to MOCs 

7.1 IOC to MOC mapping 

This table provides a mapping table between Information Object Classes and Managed Object Classes. 

Table 12: Information Object Class mapping 



Information Object Class 


Managed Object Class 


GenericIRP 


No mapping (GenericIRP is provided for sub- 
classing only). 


IRPAgent 


IRPAgent 


ManagedElement 


ManagedElement 


ManagedFunction 


ManagedFunction 


ManagementNode 


ManagementNode 


MeContext 


MeContext 


SubNetwork 


SubNetwork 


Top 


No mapping (Top is provided for sub- 
classing only) 


No mapping due to different modelling approaches. Transient situation 


BasicCmIRP 


No mapping due to different modelling approaches. Transient situation 


AlarmlRP 


No mapping due to different modelling approaches. Transient situation 


NotificationIRP 



7.2 Information relationship mapping 

This table provides a mapping table between Information Relationships and the Managed Object Classes model. 

Table 13: Information Relationship mapping 



Information Relationship 


Equivalent in the Managed Object Class Model 


MgmtAssociation 


MgmtAssociation 


SubNetwork-ManagementNode 


Mapped on naming / containment relationship. 


SubNetwork-MeContext 


Mapped on naming / containment relationship. 


SubNetwork-SubNetwork 


Mapped on naming / containment relationship. 


SubNetwork-IRPAgent 


Mapped on naming / containment relationship. 


SubNetwork-ManagedElement 


Mapped on naming / containment relationship. 


MeContext-ManagedElement 


Mapped on naming / containment relationship. 


ManagedElement-! RPAgent 


Mapped on naming / containment relationship. 


IRPAgent-GenericIRP 


Mapped on naming / containment relationship. 



7.3 Information attribute mapping 

This table provides a mapping table between Information Attributes and the Managed Object Classes model. 
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Table 14: Information Attribute mapping 



Information Relationship 


Equivalent in the Managed Object Class Model 


dnPrefix 


dnPrefix 


managedElementId 


managedElementId 


subNetworkId 


subNetworkId 


managedElementlype 


managedElementlype 


irpAgentId 


IrpAgentId 


irpid 


Irpid 


locationName 


locationName 


managementNodeld 


managementNodeld 


meContextId 


meContextId 


objectClass 


No explicit mapping. Solution set dependent. 


objectlnstance 


Managed object DN. 


system DN 


system DN 


userDefinedState 


userDefinedState 


userLabel 


userLabel 


vendorName 


vendorName 



8 Managed Object Class definitions 



8.1 



Introduction 



As already introduced in the clause 5, the present clause defines the Generic Network ResourcesIRP Network Resource 
Model. 

The corresponding Solution Set specifications provide protocol dependent object models. They provide the actual 
definitions of the managed object classes defined in this subclause in each protocol environment. One may find that the 
class names defined in the protocol-neutral model differ from those defined in the Solution Sets (e.g. due to mappings to 
existing standard models that are applicable for a specific Solution Set). 

8.2 Generic Network Resource Model (NRM) 

This subclause defines the generic managed object classes supporting the Generic Network Resources IRP. These 
object classes are protocol environment neutral and the model does not define the syntax or encoding of the classes and 
attributes. 

The model described in this subclause allows for Managed Elements to be defined for management purposes according 
to the functionality contained within them. As an example, a single implementation of a combined MSC and VLR may 
be required. However, in the implementation it is required to create a single interface for the management of this 
element. This is expected to be achieved by instantiating a ManagedElement MOC that contains the "mscFunction" 
MOC, the "vlrFunction" MOC (as in the GSM 12.xx-series of specifications), and other generic or non-UMTS specific 
MOCs as appropriate to define the manageable capability of that managed element. See also the 
managedElementType attribute in the ManagedElement MOC definition. 

It should be noted that, although this model allows for combined managed element functionality as described above, in 
this subclause only the high-level and generic MOCs are defined. UMTS MOCs modelling more specific managed 
element functionality are defined in IRPs defining NRM. 

8.2.1 Managed Object Class (MOC) diagrams 
8.2.1 .1 Inheritance hierarchy 

Figure 7 shows the inheritance hierarchy for the generic MO classes defined in this IRP. 
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SubNetwork 



MeContext 



ManagementNode 



ManagedElement 



IRPAgent 



ManagedFunction 



BulkCmIRP 



VsDataContainer 



BasicCmIRP 



Figure 7: Generic NRIV! Inheritance Hierarchy 
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8.2.1 .2 Containment/Naming and Association diagram 

Figure 8 shows the containment/naming hierarchy and the associations of the generic MO classes defined by this IRP. 

NOTE: The Managed Object containment/naming relationships are in the diagram(s) below indicated by UML 
"Aggregation by reference" ("hollow diamonds"). 
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NOTE 1 : ManagedElement may be contained in either a SubNetwork or an MeContext instance, or have no parent instance at 

all. 
NOTE 2: The listed cardinality numbers represent transient as well as steady-state numbers, and reflect all managed object 

creation and deletion scenarios. 
NOTE 3: Each instance of the vsDataContainer shall only be contained under one MOC. The vsDataContainer can be 

contained under MOCs defined in other NRMs. 
NOTE 4: If the configuration contains several instances of SubNetwork, exactly one SubNetwork instance shall directly or 

indirectly contain all the other SubNetwork instances. 
NOTE 5: The SubNetwork instance not contained in any other instance of SubNetwork is referred to as "the root SubNetwork 

instance". 
NOTE 6: ManagementNode shall be contained in the root SubNetwork instance. 
NOTE 7: If contained in a SubNetwork instance, IRPAgent shall be contained in the root SubNetwork instance. 

Figure 8: Generic NRIV! Containment/Naming and Association diagram 

Each Managed Object is identified with a Distinguished Name (DN) according to 3GPP TS 32.300 [13] that expresses 
its containment hierarchy. As an example, the DN of a Managed Element instance could have a format like: 

SubNetwork=Sweden,MeContext=MEC-Gbg-l, ManagedElement =RNC-Gbg-1 . 

Note : Both the NotificationIRP MOC and the AlarmlRP MOC are not defined in the present document. The 
corresponding lOCs are defined respectively in TS 32.302 and TS 32. 111-2. 
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8.2.2 Managed Object Class (MOC) definitions 

A general note regarding all the notification tables defined for each MOC below: Each MOC may potentially send the 
notifications listed in the notification table for the MOC. The notifications with qualifier (M) shall be supported by the 
MOC, and the notifications with qualifier (O) may be supported by the MOC. 

For example, if Notification notifyObjectCreation defined in Basic CM IRP has the qualifier (M), then if a MOC is 
defined such that it emits such a notification, this notification shall be emitted when appropriate (i.e. when a new object 
is created). If Notification notifyChangedAlarm has the qualifier (O) in Alarm IRP (see 3GPP TS 32.111-2 [11]), then if 
a MOC is defined such that it emits such a notification, this notification may or may not be emitted when appropriate. 

Further, if a notification in the qualifier column (of the MOC notification tables) has a reference to another 
specification, it means that the qualifier for the notification is specified in the referred specification. 

8.2.2.1 MOC SubNetwork 

This Managed Object Class represents a set of managed entities as seen over the Itf-N. 

A SubNetwork may have 0...N instances. It shall be present if either a ManagementNode or multiple ManagedElements 
are present (i.e. ManagementNode and multiple ManagedElement instances shall have SubNetwork as parent). 

If the configuration contains several instances of SubNetwork, exactly one SubNetwork instance shall directly or 
indirectly contain all the other SubNetwork instances. 

The SubNetwork instance not contained in any other instance of SubNetwork is referred to as "the root SubNetwork 
instance". 

Table 15: Attributes of SubNetwork 



Name 


Qualifier 


Description 


subNetworkId 


READ-ONLY, M 


An attribute whose 'name+value' can be used as an RDN when naming 
an instance of the SubNetworl< object class. This RDN uniquely 
identifies the object instance within the scope of its containing (parent) 
object instance. 


dnPrefix 


READ- ONLY, C 


It carries the DN Prefix information as defined in Annex C of 32.300 [13]. 
It shall only be specified if the instance of SubNetwork is a local root 
instance of the MIB. Otherwise the value shall carry the NULL 
semantics. 


userLabel 


READ-WRITE, M 


A user-friendly (and user assigned) name of the associated object. 


userDefinedNetworkType 


READ-ONLY, M 


Textual information regarding the type of network, e.g. UTRAN. 



Table 16: Notifications of SubNetwork 



Name 


Qualifier 


Notes 


notifyAckStateChanged 


See Alarm IRP (3GPP TS 32.111-2 [11]) 




notifyAttributeValueChange 







notifyChangedAlarm 


See Alarm IRP (3GPP TS 32.111-2 [11]) 




notifyClearedAlarm 


See Alarm IRP (3GPP TS 32.111-2 [11]) 




notifyNewAlarm 


See Alarm IRP (3GPP TS 32.111-2 [11]) 




notifyObjectCreation 







notifyObjectDeletion 







notifyComments 


See Alarm IRP (3GPP TS 32.111-2 [11]) 





8.2.2.2 



MOC ManagedElement 



This Managed Object Class represents telecommunications equipment or TMN entities within the telecommunications 
network that performs Managed Element (ME) functions, i.e. provides support and/or service to the subscriber. 
An ME communicates with a manager (directly or indirectly) over one or more interfaces for the purpose of being 
monitored and/or controlled. MEs may or may not additionally perform element management functionality. 
An ME contains equipment that may or may not be geographically distributed. An ME is often referred to as a 
"Network Element". This class is similar to the Managed Element class specified in ITU-T M.3100 [4], [5], [6]. 
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A ManagedElement may be contained in either a SubNetwork or in an MeContext instance. A single ManagedElement 
seen over the Itf-N may also exist stand-alone with no parent at all. 

The ManagedElement MOC may be used to represent combined ME functionality (as indicated by the 
managedElementType attribute and the contained instances of different functional MOCs). 

Single function ManagedElement managed object instances will have a 1..1 containment relationship to a function 
Managed Object (in this context a function MO is an MO derived from the ManagedFunction MOC). Multiple function 
ManagedElement managed object instances will have a 1..N containment relationship to function Managed Objects. 



Table 17: Attributes of ManagedElement 



Name 


Qualifier 


Description 


managed Elementld 


READ-ONLY, M 


An attribute whose 'name+value' can be used as an RDM when naming an 
instance of the ManagedElement object class. This RDN uniquely identifies 
the object instance within the scope of its containing (parent) object 
instance. 


dnPrefix 


READ- ONLY, C 


It carries the DM Prefix information as defined in Annex C of 32.300 [13]. It 
shall only be specified if the instance of IVIanagedElement is a local root 
instance of the MIB. Otherwise the value shall carry the NULL semantics. 


managedElementType 


READ-ONLY, M 


The type of managed element. It is a multi-valued attribute with one or more 

elements. Thus, it may represent one IVIE functionality, e.g. an RNC, or a 

combination of more than one functionality e.g. an IVISC/HLR. The allowed 

members of this attribute are: 

RNC, NodeB, BSS, MSC, HLR, VLR, AuC, EIR, SMS-IWMSC, SMS- 

GMSC, GMSC, SGSN, GGSN, BG, BS, GBC, CGF, GMLG, GMSC Server, 

IWF, MOW, MNP-SRF, MSC Server, NPDB, R-SGW, SCF, SMLC, SRF, 

SSF. 

The actual syntax and encoding of this attribute is Solution Set specific. 


userLabel 


READ-WRITE, M 


A user-friendly name of this object. 


vendorName 


READ-ONLY, M 


The name of the ManagedElement vendor. 


userDefinedState 


READ-WRITE, M 


An operator defined state for operator specific usage. (See also Note below) 


locationName 


READ-ONLY, M 


The physical location of this entity (e.g. an address). 


swVersion 


READ-ONLY, M 


The software version of the ManagedElement (this is used for determining 
which version of the vendor specific information is valid for the 
ManagedElement). 


managedBy 


READ-ONLY, M 


The value of this attribute shall be the DN of the related managementNode 
instance. This is a reference attribute modelling the role (of the association 
MgmtAssociation) that this ME is managed by 0-1 managementNode. 


NOTE: In addition to the userDefinedState, state management attributes are expected to be included in the next 
release. 



Table 18: Notifications of ManagedElement 



Name 


Qualifier 


Notes 


notifyAckStateChanged 


See Alarm IRP (3GPP TS 32.111-2 [11]) 




notifyAttributeValueChange 







notifyChangedAlarm 


See Alarm IRP (3GPP TS 32.111-2 [11]) 




notifyClearedAlarm 


See Alarm IRP (3GPP TS 32.111-2 [11]) 




notifyNewAlarm 


See Alarm IRP (3GPP TS 32.111-2 [11]) 




notifyObjectCreation 







notifyObjectDeletion 







notifyComments 


See Alarm IRP (3GPP TS 32.111-2 [11]) 





8.2.2.3 



MOC MeContext 



This Managed Object Class (MOC) is introduced for naming purposes. It may support creation of unique DNs in 
scenarios when some MEs have the same RDNs due to the fact that they have been manufacturer pre-configured. 
If some MEs have the same RDNs (for the above mentioned reason) and they are contained in the same SubNetwork 
instance, some measure shall be taken in order to assure the global uniqueness of DNs for all MOIs under those MEs. 
One way could be to set different DnPrefixes for those NEs, but that would require either that: 
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a) all LDNs or DNs are locally modified using the new DnPrefix for the upper portion of the DNs, or 

b) a mapping (translation) of the old LDNs or DNs to the new DNs every time they are used externally, e.g. in alarm 
notifications. 

As both the two alternatives above may involve unacceptable drawbacks (as the old RDNs for the MEs then would have 
to be changed or mapped to new values), using MeContext offers a new alternative to resolve the DN creation. Using 
MeContext as part of the naming tree (and thus the DN) means that the DnPrefix, including a unique MeContext for 
each ME, may be directly concatenated with the LDNs, without any need to change or map the existing ME RDNs to 
new values. 

MeContext have 0..N instances. It may exist even if no SubNetwork exists. Every instance of MeContext contains 
exactly one ManagedElement during steady-state operations. 

Table 19: Attributes of MeContext 



Name 


Qualifier 


Description 


meContextId 


READ-ONLY, M 


An attribute whose 'name-i-value' can be used as an RDN when naming an instance of 
this object class. This RDN uniquely identifies the object instance within the scope of 
its containing (parent) object instance. 


dnPrefix 


READ- ONLY, C 


It carries the DN Prefix information as defined in Annex C of 3GPP TS 32.300 [13]. It 
shall only be specified if the instance of MeContext is a local root instance of the MIB. 
Otherwise the value shall carry the NULL semantics. 



Table 20: Notifications of MeContext 



Name 


Qualifier 


Notes 


notifyAckStateChanged 


See Alarm IRP (3GPP TS 32.1 11-2 [11]) 




notifyAttributeValueChange 







notifyChangedAlarm 


See Alarm IRP (3GPP TS 32.111-2 [11]) 




notifyClearedAlarm 


See Alarm IRP (3GPP TS 32.111-2 [11]) 




notifyNewAlarm 


See Alarm IRP (3GPP TS 32.111-2 [11]) 




notifyObjectCreation 







notifyObjectDeletion 







notifyComments 


See Alarm IRP (3GPP TS 32.111-2 [11]) 





8.2.2.4 



MOC ManagementNode 



This Managed Object Class represents a telecommunications management system (EM) within the TMN that contains 
functionality for managing a number of Managed Elements (MEs). The management system communicates with the 
MEs directly or indirectly over one or more interfaces for the purpose of monitoring and/or controlling these MEs. 

This class has similar characteristics as the ManagedElement. The main difference between these two classes is that the 
ManagementNode has a special association to the managed elements that it is responsible for managing. 

A ManagementNode instance shall be contained in the root SubNetwork instance. 
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Table 21 : Attributes of ManagementNode 



Name 


Qualifier 


Description 


managementNodeld 


READ-ONLY, M 


An attribute whose 'name-i-value' can be used as an RDN when 
naming an instance of this object class. This RDN uniquely 
identifies the object instance within the scope of its containing 
(parent) object instance. 


userLabel 


READ-WRITE, M 


A user-friendly name of this object. 


vendorName 


READ-ONLY, M 


The name of the IVIanagementNode vendor. 


userDefinedState 


READ-WRITE, M 


An operator defined state for operator specific usage. 


locationName 


READ-ONLY, M 


The physical location of this entity (e.g. an address). 


swVersion 


READ-ONLY, M 


The software version of the management node (this is used for 
determining which version of the vendor specific information is 
valid for the management node). 


manages 


READ-ONLY, M 


The value of this attribute shall be a list of the DN(s) of the related 
ManagedElement instance(s). This is a reference attribute 
modelling the role (of the association MgmtAssociation) that this 
managementNode is responsible for managing 0-N MEs. 



Table 22: Notifications of ManagementNode 



Name 


Qualifier 


Notes 


notifyAckStateChanged 


See Alarm IRP (3GPP TS 32.1 11-2 [11]) 




notifyAttributeValueChange 







notifyChangedAlarm 


See Alarm IRP (3GPP TS 32.111-2 [11]) 




notifyClearedAlarm 


See Alarm IRP (3GPP TS 32.111-2 [11]) 




notifyNewAlarm 


See Alarm IRP (3GPP TS 32.111-2 [11]) 




notifyObjectCreation 







notifyObjectDeletion 







notifyComments 


See Alarm IRP (3GPP TS 32.111-2 [11]) 





8.2.2.5 



MOC ManagedFunction 



This Managed Object Class is similar to the class gsmManagedFunction defined in GSM 12.20 [12] and is 
provided for sub-classing only. It provides the attributes that are common to functional MO classes. Note that a 
Managed Element may contain several managed functions. The ManagedFunction may be extended in the future if 
more common characteristics to functional objects are identified. 

Table 23: Attributes of ManagedFunction 



Name 


Qualifier 


Description 


userLabel 


READ-WRITE, M 


A user-friendly name of the associated object. 



8.2.2.6 MOC IRPAgent 

This Managed Object Class represents the functionality of an IRPAgent. It shall be present. For a definition of 
IRPAgent, see 3GPP TS 32.102 [2]. 

If an IRPAgent instance is contained in a SubNetwork instance, this instance shall be the root SubNetwork instance. 

Restriction in R4: The IRPAgent will be contained under a managed object as follows (only one of the options shall be 
used): 

4. ManagementNode, if the configuration contains a ManagementNode; 

5. SubNetwork, if the configuration contains a SubNetwork and no ManagementNode; 

6. ManagedElement, if the configuration contains no ManagementNode or SubNetwork. 
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Table 24: Attributes of iRPAgent 



Name 


Qualifier 


Description 


irpAgentId 


READ-ONLY, M 


An attribute whose 'name-nvalue' can be used as an RDN when naming an 
instance of this object class. This RDN uniquely identifies the object instance 
within the scope of its containing (parent) object instance. 


system DN 


READ-ONLY, C 


The Distinguished Name (DN) of IRPAgent. Defined in 3GPP TS 32.302 [3]. 



Table 25: Notifications of IRPAgent 



Name 


Qualifier 


Notes 


notifyAcl<StateChanged 


See Alarm IRP (3GPP TS 32.111-2 [11]) 




notifyAttributeValueChange 







notifyChangedAlarm 


See Alarm IRP (3GPP TS 32.1 1 1 -2 [1 1]) 




notifyClearedAlarm 


See Alarm IRP (3GPP TS 32.1 1 1 -2 [1 1]) 




notifyNewAlarm 


See Alarm IRP (3GPP TS 32.111-2 [11]) 




notifyObjectCreation 







notifyObjectDeletion 







notifyComments 


See Alarm IRP (3GPP TS 32.1 1 1 -2 [1 1]) 





Note that these notifications are issued based on occurrences on the IRPAgent MOC and not on occurrences on other 
Basic CM IRP managed objects. 



8.2.2.7 



MOC VsDataContainer 



The 'VsDataContainer' managed object is a container for vendor specific data. The number of instances of the 
'VsDataContainer' can differ from vendor to vendor. This MOC shall only be used by the Bulk CM IRP for the UTRAN 
and GERAN object models. 

Table 26: Attributes of VsDataContainer 



Name 


Qualifier 


Description 


vsDataContainerld 


READ-ONLY, M 


An attribute whose 'name-i-value' can be used as an RDN when 
naming an instance of this object class. This RDN uniquely identifies 
the object instance within the scope of its containing (parent) object 
instance. 


vsDataType 


READ-ONLY, M 


Type of vendor specific data contained by this instance, e.g. relation 
specific algorithem parameters, cell specific parameters for power 
control or re-selection or a timer. The type itself is also vendor 
specific. 


vsData 


READ-WRITE, M 


Vendor specific attributes of the type vsDataType. The attribute 
definitions including constraints (value ranges, data types, etc.) are 
specified in a vendor specific data format file. 


vsDataFormatVersion 


READ- ONLY,IVI 


Name of the data format file, including version. 



8.2.2.8 



MOC Notification IRP 



This Managed Object Class represents the Notification IRP capability associated with each IRPAgent. At least one 
instance shall be present for every IRPAgent instance. Restriction in R4: Number of instances = 1. 

Table 27: Attributes of Notif icationiRP 



Name 


Qualifier 


Description 


notificationlRPId 


READ-ONLY, IVI 


An attribute whose 'name-i-value' can be used as an RDN when naming an 
instance of this object class. This RDN uniquely identifies the object 
instance within the scope of its containing (parent) object instance. 


irpVersion 


READ-ONLY, M 


One or more Notification IRP version entries. 
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8.2.2.9 



MOC AlarmlRP 



This Managed Object Class represents the Alarm IRP (see 3GPP TS 32. 11 1-2 [11]) capability associated with each 
IRP Agent. Restriction in R4: Number of instances = 0..1. 

Table 28: Attributes of AlarmiRP 



Name 


Qualifier 


Description 


alarmlRPId 


READ-ONLY, M 


An attribute whose 'name-nvalue' can be used as an RDN when naming an instance 
of this object class. This RDN uniquely identifies the object instance within the 
scope of its containing (parent) object instance. 


irpVersion 


READ-ONLY, M 


One or more Alarm IRP (see 3GPP TS 32.1 1 1-2 [1 1]) version entries. 



Table 29: Notifications of AlarmiRP 



Name 


Qualifier 


Notes 


notifyAlarmListRebuilt 


See Alarm IRP (3GPP TS 32.111-2 [11]) 





8.2.2.10 



MOC BasicCmIRP 



This Managed Object Class represents the Basic CM IRP capability associated with each IRP Agent. Restriction in R4: 
Number of instances = 0..1. 

Table 30: Attributes of BasicCmiRP 



Name 


Qualifier 


Description 


basicCmlRPId 


READ-ONLY, M 


An attribute whose 'name-nvalue' can be used as an RDN when naming an 
instance of this object class. This RDN uniquely identifies the object instance 
within the scope of its containing (parent) object instance. 


irpVersion 


READ-ONLY, M 


One or more Basic CIVI IRP version entries. 



8.2.2.11 



MOC BulkCmIRP 



This Managed Object Class represents the Bulk CM IRP capability associated with each IRP Agent. Restriction in Rel- 
4: Number of instances = 0..1. 

Table 31 : Attributes of BulkCmiRP 



Name 


Qualifier 


Description 


bulkCmlRPId 


READ-ONLY, M 


An attribute whose 'name-nvalue' can be used as an RDN when naming an 
instance of this object class. This RDN uniquely identifies the object instance 
within the scope of its containing (parent) object instance. 


irpVersion 


READ-ONLY, M 


One or more Bulk CM IRP version entries. 



Table 32: Notifications of BulkCmiRP 



Name 


Qualifier 


Notes 


notifySessionStateChange 


M 




notifySessionLogStatus 


M 





8.3.3 Associations 



8.3.3.1 



Association MgmtAssociation (M) 



This association is used to represent relationships between one or more MEs and the ManagementNode that is 
responsible for managing the MEs. It has two roles, named Manages and ManagedBy. The role 'Manages' models the 
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fact that a ManagementNode is responsible for managing zero or more MEs, and the role ManagedBy models the fact 
that an ME is managed by zero or one ManagementNode. Each role is in the MOC definition mapped to a reference 
attribute with the same name. 
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Annex A (informative): 
Change history 
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4.0.0 
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— 
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4.1.0 
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003 


-- 


Correct description of swVersion attribute 
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4.1.0 
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004 
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